home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 6313 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: faatcrl.faa.gov!saratoga!lbona
  2. From: lbona@saratoga (lbona)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: returning ptr to struct with ptrs in it?
  5. Date: 23 Feb 1996 21:50:53 GMT
  6. Organization: FAA Technical Center, Pomona, NJ
  7. Message-ID: <4glcrtINNf4b@faatcrl.faa.gov>
  8. References: <4gk852INNbp4@faatcrl.faa.gov>
  9. Reply-To: lbona@tgf.tc.faa.gov
  10. NNTP-Posting-Host: 155.178.247.116
  11. X-Newsreader: Tin 1.1 PL4
  12.  
  13. lbona@saratoga (lbona) writes:
  14. : 
  15. : The following is beyond the scope of my knowledge. Perhaps someone can explain
  16. : it to me:
  17. : 
  18. : When I declare a function that returns a pointer to a struct that contains 
  19. : pointers, the pointer(s) at the end of the struct get set to garbage after 
  20. : being returned. Pointers not at the end are not affected.
  21.  
  22.  
  23. When I posted this question I had just finished an all-night coding
  24. session and my brain was mush. As a result my question wasn't as
  25. clear as I thought, actually it was misleading.
  26.  
  27. What I was trying to get at was this: When I declare a local variable, 
  28. bb, I know it's using temp memory off the stack. When the variable goes
  29. out of scope, i.e. leaving the function, the memory is returned to the
  30. stack. However, it is not cleared (compiler dependant of course), the 
  31. data stays the same until something else needs the memory. This is why 
  32. all the fields in the struct still have the correct values and I can 
  33. assign them to a struct, BB, of the same type that is still extant.
  34.  
  35. My real question is: why is it that if the struct ends with a pointer
  36. or pointers, that area of memory is corrupted (made non-zero in this case)
  37. yet if the struct ends in a non-pointer field the area of memory in 
  38. question is not changed? All the data is the same, including pointers in 
  39. the middle of the struct.
  40.  
  41. Anyway, as I said in my original post, I know it's better to pass the
  42. address of the struct in question to the function, and that's what I'll
  43. be doing, but this struck me as strange, and I was curious as to what
  44. was happening.
  45.  
  46.  
  47. : --------------------------------------------------------------
  48. : 
  49. : typedef struct aaa {
  50. :   int i;
  51. :   char name[22];
  52. :   int id;
  53. : } AAA;
  54. : 
  55. : typedef struct bar {
  56. :   long a;
  57. :   long b;
  58. :   int c;
  59. :   AAA *d;
  60. :   char e;
  61. :   char f[100];
  62. :   AAA *g;
  63. :   AAA *h;
  64. : } BAR;
  65. : 
  66. : BAR *parse_bar(char toke[]);
  67. : 
  68. : main()
  69. : {
  70. : BAR BB;
  71. : char toke[128];
  72. : 
  73. :   memset(&BB,0,sizeof(BAR));
  74. :    /* at this point BB.d == BB.g == BB.h == NULL */
  75. : 
  76. :     /* toke is an ascii string read in from a file */
  77. :   BB = *parse_bar(toke);
  78. : 
  79. :   /* at this point BB.g and BB.h are garbage, but all the other fields */
  80. :   /* in BB are correct including BB.d*/
  81. : 
  82. : }
  83. : 
  84. : 
  85. : BAR *parse_bar(char toke[]);
  86. : {
  87. : BAR bb;
  88. : 
  89. :   memset(&bb,0,sizeof(BAR));
  90. :    /* at this point BB.d == BB.g == BB.h == NULL */
  91. : 
  92. :   /* read data from file and parse - never touch bb.d, bb.g, or bb.h */
  93. : 
  94. :    /* at this point BB.d == BB.g == BB.h == NULL */
  95. :   return(&bb);
  96. : }
  97. : 
  98. : 
  99. : ----------------------------------------------------------
  100. : 
  101. : I know there are several work arounds, and that it's better to pass the address
  102. : of BB to parse_bar(), which is what I'll be doing. But I'm curious why this is
  103. : happening. I've tried it under K&R on Unix and ANSI on DOS and the results
  104. : were identical.
  105. : 
  106. : 
  107. : Any help would be appreciated,
  108. : 
  109. : thanks
  110. : 
  111. : --
  112. : 
  113. : Lou Bona
  114. : lbona@tgf.tc.faa.gov
  115. : 
  116.  
  117. --
  118.  
  119. Lou Bona
  120. lbona@tgf.tc.faa.gov
  121.  
  122.